<!DOCTYPE html><html lang="ru" dir="ltr" spellcheck><head><!--#include file="h.htm"--><meta name="description" content="Пиццикато Алексея Лота. Полезные высказывания из книги 'Правила разработки программного обеспечения' Маккарти."><meta name="keywords" content="сайт алексея лота, технологии, маккарти, правила разработки, программного обеспечения, разработка по, алексей лот"><title>Полезные высказывания из книги "Правила разработки программного обеспечения" Маккарти</title></head><body><header><h1 class=m>Пиццикато Алексея Лота</h1><nav><a href="p.htm">Главная</a><a href="m.htm">Песни</a><a href="l.htm">Психология</a><a href="r.htm">Рассказы</a><a href="b.htm">Религия</a><a href="s.htm">Стихотворения</a><a id="i" href="t.htm">Технологии</a><a href="f.htm">Философия</a><a href="i.htm">Фотография</a></nav></header><article id="c"><h2 class=m>Полезные высказывания из книги "Правила разработки программного обеспечения" Маккарти</h2><div id="w">Разработка качественного ПО концептуально:<br>изучить пользователей и позиционировать себя на рынке;<br>определить спецификацию продукта, который соответствуетзапросам рынка;<br>разработать ПО, выпустить его, занять достойное место в ряду основных производителей.<br><br>Запаздывание - обычное явление в разработке ПО.<br><br>Истинная задача управления разработкой ПО - привлечь как можно больше интеллекта и вкладывать его во все сферы деятельности, связанные с созданием программного продукта с применением всех дисциплин.<br><br>Интеллект проявляется в качествах:<br>творчество;<br>ум;<br>рассудительность;<br>эффективность;<br>четкость.<br><br>Самое трудное в процессе разработки ПО - добиться действительного участия создателей.<br><br>Основные аспекты деятельности в разработке:<br>как заставить человека думать;<br>о чём люди должны думать;<br>как сделать человеческие мысли эффективными.<br><br>Поставка качественного ПО в срок просто дело применения здравого смысла.<br><br>Программист - ювелир.<br><br>Поощрять умственную деятельность.<br><br>Устранять причины, а не людей.<br><br>Большинство ресурсов должно уходить на интеллектуальную деятельность, а не в механические усилия.<br><br>Первостепенная обязанность руководителя - вовлечь каждого работника в процесс и держать его в этом процессе на протяжении всего проекта.<br><br>Программный проект - это процесс, проходящий 4 основные стадии:<br>начальные шаги - создание разумной маркетинговой стратегии, проектирование продукта, создание клана разработки и первые шаги по разработке (собрать работоспособную команду из хаоса, который царит в фирме);<br>середина игры - длительный промежуток времени, начинающийся с первого нарушения графика разработки и оканчивающийся наступлением ражима выпуска;<br>режим выпуска - время выпуска продукта;<br>запуск - время, когда продукт считается выпущенным.<br><br>Области действий хорошей разработки:<br>организация;<br>конкуренция;<br>клиент;<br>проектирование;<br>разработка.<br><br>Коллектив разработчиков выполняет следующие функции:<br>управление проектом: создавать план разработки, вести внешние связи, снабжать необходимыми ресурсами, участвовать в проектировании;<br>контроль качества: оценивать качество продукта, участвовать в проектировании;<br>разработка: писать программный код, отлаживать программы, участвовать в проектировании;<br>управление продуктом, маркетинг: создавать план выпуска сообщений и продукта, осуществлять связь с клиентом, участвовать в разработке;<br>документация и обучение пользователей: систематизировать информацию, необходимую для использования продукта, участвовать в проектировании.<br><br>Главная функция контроля качества - постоянно оценивать состояние продукта, чтобы правильно сфокусировать деятельность всех членов команды.<br><br>Состояние продукта=тестирование и анализ.<br><br>Фирма не должна перемешивать желаемое с действительным.<br><br>Не должно быть борьбы за официально установленные полномочия.<br><br>Цель проектирования продукта в том, чтобы в его основу легли лучшие идеи.<br><br>Все споры о том, что лучше, должны быть решены до начала разработки.<br><br>Ссоры - выражение проблем, которые возникли в команде.<br><br>Распределять роли до начала разработки.<br><br>Для поддержания работоспособной, слаженной команды необходимо общее видение.<br><br>Для достижения равновесия нужно действовать в более узких рамках, специализироваться и конкурировать.<br><br>Каждый член команды должен знать:<br>что будет делать команда;<br>как будет выглядеть конечный продукт;<br>какова базовая стратегия создания продукта;<br>когда команда должна выпустить продукт, чтобы получить от него ожидаемый эффект.<br><br>Все возникшие противоречия должны быть разрешены.<br><br>Хорошие лидеры любого уровня должны передавать свое видение приверженцам.<br><br>Установить в команде режим сопереживания.<br><br>Что делали бы эти люди на моем месте?<br><br>Как преобразовать их сложные чувства в ясный приказ о действиях?<br><br>Привлекать каждую голову в дело.<br><br>Если каждый член команды постоянно думает, какое поведение эффективнее всего в данном случае, то есть вероятность, что дела команды пойдут лучше.<br><br>Выслушивать все идеи.<br><br>Чем больше идей, тем лучше.<br><br>Идеи людей должны применяться.<br><br>Создать технологический план выпуска версий.<br><br>Технологический план - обновляемый 1-2 раза в год контракт, выражающий намерения команды.<br><br>Не реализовывать все задумки именно в этой версии.<br><br>Для отслеживания инвестиций и трудностей делить план на стратегические, конкурентные, ориентированные на клиента, инвестиционные и парадигматические отличительные особенности.<br><br>Когда кажется, что кто-то сумасшедший, тупой или убогий, то обычно следует более тщательно изучить человека, а не списывать его.<br><br>Обеспечить адекватное восприятие критики.<br><br>Правильно балансировать нагрузки в проекте.<br><br>Исключить перегорание разработчиков.<br><br>Провести разведку перед началом нового проекта, особенно для требований.<br><br>Использовать последние версии инструментов.<br><br>Прогнозировать версии сред, в которых будет эксплуатироваться продукт.<br><br>Необходимо соблюдать пропорции в численности команды по ролям.<br><br>У каждого одна своя роль.<br><br>Группа автора:<br>6 разработчиков;<br>2-3 контролера качества;<br>1 руководитель проекта;<br>2 технических писателя.<br><br>Контролер качества должен проектировать продукт и знать потребителей.<br><br>Можно добавить в команду маркетологов.<br><br>Управление областями по отдельным дисциплинам поручать ведущим специалистам в области.<br><br>Команда должна нести совместную ответственность за все аспекты.<br><br>Жест обратной связи гасит агрессию.<br><br>Необходимый команде консенсус достигается ценой бессонных ночей, страха быть отвергнутым, испытаний личной храбрости.<br><br>Члены команды приходят к выводу, что могут действовать свободно и несут ответственность за свои действия.<br><br>Не должно быть поддакивания, фальшивого консенсуса.<br><br>Члены команды должны осознать, что им никто не мешает.<br><br>Каждого человека надо вдохновлять и подпитывать.<br><br>Поначалу становлению команды могут препятствовать ее члены.<br><br>В идеальном проекте имеются создатели- специализируются в разработке, контроле качества, маркетинге, документировании и так далее, и кураторы - специализируются в понимании группы, создании обстановки для творческой работы и эффективной реализации идей.<br><br>Кураторы обеспечивают включение максимального количества идей в коробку с программным продуктом.<br><br>Кураторы и создатели ответственны за качество и состояние группы.<br><br>Единственная власть идет от знания и понимания, а не от занимаемой позиции.<br><br>Руководители проекта выполняют функции:<br>возглавляют определение успешного продукта;<br>возглавляют распространение видения продукта;<br>возглавляют движение команды к гарантированной поставке продукта.<br><br>Руководитель проекта не имеет прямой власти.<br><br>Роль руководителя проекта - лидерство.<br><br>Управление проектом - техническая задача.<br><br>2 аспекта технического мастерства: технология, используемая при создании ПО, продукта и технические аспекты лидерства при создании ПО.<br><br>Руководитель проекта должен уметь уговаривать, содействовать, внушать вдохновление, требовать совершенства, эффективной работы от остальных членов команды, быть представителем для прессы, клиентов и руководства корпорации.<br><br>Руководитель проекта - сердце разработки ПО.<br><br>ПО выражает команду, его создавшую.<br><br>Следить не за словами и поведением команды, а оценивать ее по ПО.<br><br>Анализ проблем в команде - способ привести ПО в порядок.<br><br>Постоянно поддерживать контакт с духом команды.<br><br>Сложные чувства и идеи должны свободно передаваться внутри команды.<br><br>Сделать максимально полной властью каждого члена команды.<br><br>В команде не должно быть авторитетов и кумиров.<br><br>Вводить команду в курс дела, чтобы сформировать адекватные ожидания.<br><br>Менеджеры обеспечивают принятие командой хорошего решения - обучением, информацией, адекватными ресурсами любого вида.<br><br>В среде с правильным наделением полномочиями, ситуация не анархическая и конфронтационная, а основанная на способностях людей.<br><br>Сфокусировать внимание команды на выпуске продукта.<br><br>Игнорировать иерархические и функциональные границы.<br><br>Задача создания ПО не имеет отношения к тому, кто и какие принимает решения, кто и за что вознаграждает, кто и за что наказывает.<br><br>Четыре основные ситуации на рынке:<br>Вы один на рынке;<br>Вы идёте бок о бок с конкурентом;<br>Вы отстаёте от конкурента;<br>Вы опережаете конкурента.<br><br>Необходимо знать в каком направлении развивается рынок, кто конкуренты, каковы их возможности, как их опередить.<br><br>Человек генетически предрасположен к командной работе.<br><br>Люди в вашей группе были отобраны эволюционно.<br><br>Как только поставлен диагноз ситуации, сразу обудить классические ходы.<br><br>Рынка без конкуренции не бывает.<br><br>Комплекс задач: создание отличительных преимуществ, разработка технологического плана.<br><br>Перегруженный функциями и отличительными особенностями подукт становится раздутым и ненадежным.<br><br>Силовой подход: опередить конкурента по числу отличительных особенностей или добавить парадигматические особенности, меняющие архитектуру.<br><br>При неудаче сохранить расходы на пиар.<br><br>Выпустить раньше, чем это сделают конкуренты.<br><br>При лидерстве самодовольство - враг.<br><br>Лидерство не будет вечно.<br><br>Надо конкурировать с самим собой.<br><br>Работать над увеличением скорости перемен.<br><br>Пресекать все попытки возврата к худшему.<br><br>Не позволять людям успокаиваться и замедлять движение.<br><br>Цикл ПО связан с выпусками ОС.<br><br>Проектировать желаемость продукта с самого начала.<br><br>Принимать во внимание психо-эмоциональное состояние клиента, в котором он использует компонент.<br><br>Нормальная успешная фирма в версии за версией отвечает на самые жесткие требования клиентов.<br><br>Рынок хочет делать на компьютерах то, что раньше на них не делалось.<br><br>Спрашивать клиентов об их нуждах всегда и везде.<br><br>Проводить статистические исследования.<br><br>Всегда думать о власти, безопасности и управлении.<br><br>Не будьте непостоянны с вашими клиентами.<br><br>Сокращать время цикла разработки.<br><br>Наличные деньги никогда не лгут.<br><br>Клиент должен быть в состоянии прогнозировать сроки и возможный эффект следующей версии.<br><br>Клиенты предпочитают новое ПО обещаниям.<br><br>Проанализируйте значение вашей работы в исторических терминах.<br><br>В ПО каждый элемент существенен для целого, и все существенные элементы присутствуют.<br><br>Пользователю ничего, кроме продукта, не нужно.<br><br>Тема (theme) ПО - преобладающая идея, создающая основу для проектирования.<br>Определив тему, нужно жертвовать другими качествами.<br><br>Элементы продукта получают внимание пропорционально их важности.<br><br>Ранние части ПО определяют более поздние.<br><br>Минимизировать зависимости.<br><br>Исключить самую вероятную опасность.<br><br>Тщательно выбирать платформу.<br><br>Утанавливать сроки на стадии проектирования.<br><br>Разработка=планирование, составление графиков, создание и развертывание ПО.<br><br>Создавать контрольные точки.<br><br>Не слушать некомпетентных приказов.<br><br>В сумасшедшем доме здоровый человек считается сумасшедшим.<br><br>Не позволять абсурду и неразумности укреплять позиции.<br><br>В середине игры цели- стойкость и упорство.<br><br>Некоторый риск существует даже в простых процедурах.<br><br>Не поддаваться страхам команды.<br><br>Треугольник: отличительные особенности, ресурсы, время.<br><br>Запросивший помощь должен максимизировать эффективность количества и типа помощи. В таких случаях ничего нельзя сказать наверняка.<br><br>Явно озвучитвать ваше незнание, чтобы все понимали истинное положение вещей.<br><br>Вести списки относящихся к делу аспектов, которые на данный момент неизвестны.<br><br>Предпосылками успеха являются лишения и разочарования.<br><br>Не замалчивать неопределенности.<br><br>Равновесие, созгласованность, целостность.<br><br>Мысли=слова=дела.<br><br>Сдаваемые объекты должны появляться через небольшие промежутки времени.<br><br>В разработке запаздывали все.<br><br>Задача разработки - формирование группы, способной создать и выполнить сотни маленьких, но существенных обязательств.<br><br>Не оставлять разработчиков наедине с собой.<br><br>Продукт следует собирать с незначительными интервалами.<br><br>Не уходить в темноту.<br><br>Функциональность системы не должна теряться.<br><br>Текущая сборка - это текущее состояние команды.<br><br>Достигнуть состояния ясности и оставаться в нем.<br><br>Иметь выпускаемый продукт каждый день.<br><br>Нужен человек, занимающийся формулированием состояния дел.<br><br>Использовать метрики каждый день.<br><br>Намечать контрольные точки для каждой, даже самой маленькой задачи.<br><br>Для контрольных точек назначать уровень качества.<br><br>Команде необходимо осознавать свое состояние.<br><br>Цели контрольной точки выражаются в терминах объектов сдачи.<br><br>Объекты сдачи передаются с письменным подтверждением заинтересованных лиц.<br><br>В команде производить балансировку нагрузки.<br><br>Каждую контрольную точку обсуждать без поиска виновных.<br><br>Выдвинуть на первый план моменты, которые были сделаны хорошо.<br><br>Не наказывать за опоздание в контрольной точке.<br><br>Контрольная точка: что будет передано, кому, в какой форме?<br><br>В команде - свобода высказываний.<br><br>К каждой контрольной точке выработать норматив.<br><br>Пренебречь элементами, представляющими избыточную сложность.<br><br>Контрольные точки от 6 недель до 3 месяцев друг от друга.<br><br>В проекте не более 7 контрольных точек.<br><br>К каждой контрольной точке формулируется 1-2 предложения, описывающих путь достижения.<br><br>Обсуждать с командой ситуацию и разрабатывать согласованный план действий.<br><br>Каждый новый проект начинается на нулевом уровне реальности.<br><br>Опоздания и ошибки не имеют отношения к проигрышу или вине.<br><br>Делать допуски в определении дат.<br><br>Не кричать о пугающем состоянии дел часто.<br><br>Что говорит о себе команда своим поведением?<br><br>Не искать козла отпущения.<br><br>Не переносить даты.<br><br>После опоздания следующая контрольная точка должна быть достигнута.<br><br>Делать опоздание положительным переживанием.<br><br>Наблюдать за всем.<br><br>Не все изменения следует принимать и реализовывать.<br><br>Анализировать причины и цели проблем.<br><br>Изменяться вместе с миром.<br><br>Не принуждать людей работать по вечерам и выходным.<br><br>Нарушать правила - разработчики любят вставать против власти и структуры.<br><br>Применять символическое общение.<br><br>Бета-версии должны обеспечить проверку работы продукта на как можно большем числе машинных конфигураций.<br><br>Никакие реальные изменения, за исключением исправлений конфигурационных проблем, не вносятся, а переходят в следующую версию.<br><br>У маркетологов должна быть эмоциональная модель клиентов.<br><br>Критерии сортировки дефектов: серьезность дефекта, важность, размер, возможность дестабилизации ПО при исправлении дефекта, динамика командыыыыы, степень полноты тестирования продукта после исправления дефекта.<br><br>Качество включает в себя новизну проекта и его исключительность.<br><br>Фанфары - важная часть отношений с клиентом.<br><br>Все события, предшествующие событию запуска и следующие за ним, должны быть строго расписаны.<br><br>История продукта должна быть оригинальной житейской мудростью.<br><br>У людей нет ни времени, ни желания овладевать сложными вопросами.<br><br>Хороший рассказ - настроение, замысел, хорошие и плохие парни, накал страстей и сцены погони.<br>1-2 ключевых фактов достаточно.<br><br>Сделать так, чтобы слушатель выводил сам главную вещь, но не сообщать ее.<br><br>Мода - мощный мотивирующий фактор.<br><br>Пользователи индентифицируют себя с ПО.<br><br>Член команды должен быть прежде всего сообразительным.<br><br>Неповторимость - наиболее видимое проявление интеллекта.<br><br>Ставить кандидатам реальные задачи.<br><br>Дать людям команды перспективу.<br><br>Здоровые люди от голода не умирают.<br><br>Все новое встречает противодействие.<br><br>Почти всегда легче использовать сильные стороны человека, чем исправлять его недостатки.<br><br>Не бойтесь показать свою уязвимость.<br><br>Использовать более функциональную модель для регулирования отношений между боссами и подчиненными.<br><br>Босс - клиент, разработчик - поставщик услуг.<br><br>Если босс собирается сделать глупость, то не реагировать.<br><br>Оказание наилучших услуг не граничит с самоунижением.<br><br>Когда в группе отсутствует функциональный порядок или иерархия, в группе всегда присутствует борьба (скрытая или явная) за позиции и связанная альфа-энергия.<br><br>Применять атаку с поклоном.<br><br>Вы не насладитесь удобствами и особенностями здания до тех пор, пока не поселитесь в нем.<br><br>Удаленность - центральная проблема в коллективе.<br><br>Свободное выражение эмоций в группе.<br><br>Каждый должен знать, чего он хочет, и чего от него хотят.<br></div></article><br><footer>&copy;&nbsp;<i>Copyright&nbsp;<a href="https://алексейлот.рф">алексейлот.рф</a>&nbsp;-&nbsp;возьми главную ноту</i></footer></body></html>
